Grupo 5 - Camyo

En esta página se encuentra el feedback recogido por el equipo del grupo 5 durante las sesiones de clase. Con secciones para cada semana, se detallan los comentarios y sugerencias del profesor y los compañeros, así como las tareas a realizar para la siguiente semana. Además, se incluye una sección para otros grupos con el feedback proporcionado por el grupo 5.

Semana 1

Feedback relacionado con la presentación

• Diseño de diapositivas:
  • Aumentar el tamaño de la fuente para mejorar la legibilidad.
  • Evitar el exceso de texto y detalles innecesarios (por ejemplo, en la diapositiva de costes).
  • Aprovechar mejor el espacio en las diapositivas.
  • Alinear el estilo de los mockups e imágenes con el diseño de la presentación.
  • No incluir diapositivas que no se vayan a comentar.
• Reporte de IA: Solo incluir aspectos específicos y relevantes. Evitar contenido genérico.
• Teatro y conclusión: El uso del teatro y la conclusión final ha sido efectivo.

Feedback relacionado con el desarrollo del proyecto

• Competidores: No se han identificado suficientes competidores. Es necesario profundizar en el análisis de competidores y destacar claramente cómo nos diferenciamos de ellos.
• Diferenciación: Explicar qué hacemos que nuestros competidores no hacen (por ejemplo, Uber). Destacar nuestras fortalezas y por qué nuestra idea puede triunfar.
• DAFO: El análisis DAFO debe ser más intuitivo y enfocado en minimizar debilidades y riesgos.

Tareas a realizar para la siguiente semana

• Refinar la idea clave de mejora (business statement).
• Refinar el tipo de negocio.
• Análisis de competidores exhaustivo. Profundizar en detalle.
• Análisis de los sistemas, objetivos y modelos de negocio.
• Validar que los usuarios piloto estarían dispuestos a pagar por la idea.
• Análisis de costes, incluyendo el TCO.
• Tener al menos 12 usuarios pilotos, idealmente entre 20 y 30.
• Definir cómo interactuar con los usuarios piloto (reuniones, comunicaciones, etc.).
• Esbozar un mock-up de las funcionalidades core del MVP, centrándose en la funcionalidad, no en el diseño.
• Incluir análisis de innovación y tecnologías innovadoras.
• Análisis del equipo: habilidades y charter goal.
• Mencionar el commitment agreement, si está firmado y su relevancia.
• Esbozar análisis de riesgos y planes de contingencia.

Semana 2

Feedback relacionado con la presentación

• Diseño de diapositivas:
  • Mostrar wireframes legibles, incluso si es solo una parte de la pantalla.
  • Menos diapositivas y dar tiempo para entender las más importantes.
  • Letra blanca solo sobre fondo negro. Evitar colores claros en fondo blanco.
  • Mezclar bien imagen y texto.
  • Hacer zoom en los mockups para mostrar funcionalidades core.
  • Todas las palabras deben ser legibles desde lejos.
• Estructura de la presentación:
  • Inicio efectivo con teatro.
  • Elevator pitch ha gustado.

Feedback relacionado con el desarrollo del proyecto

• MVP (Producto Mínimo Viable):
  • Demasiadas funcionalidades core.
  • Considerar un verificado para camioneros como futura mejora.
  • Los casos de uso core propuestos no son realmente core (diferencia entre mockup y aplicación real).
• Análisis de Competidores:
  • No incluir demasiados competidores en las diapositivas.
  • Explicar cómo se han encontrado los competidores (esto está en el documento, pero no en la presentación).
  • Demasiados competidores pueden poner en duda la innovación del proyecto.
• Análisis de Coste:
  • Poner solo detalles de costes visibles.
  • Preferir bruto/neto en vez de IVA/no IVA.
  • Incluir cómo/cuándo se vuelve rentable: hora básica de servicio.
  • Estimación de usuarios y porcentaje de mercado para rentabilidad.
  • En coste de personal, incluir lo que cuesta a la empresa.
  • Para el TCO, hacerlo por meses, no por años.
  • Incluir coste de GitHub para desarrollo.
• Usuarios Pilotos:
  • Códigos QR en la presentación fue una buena idea.
  • 15-20 usuarios pilotos es recomendable, si es posible más.
• Análisis de Equipo:
  • Determinar roles dentro de los subgrupos: secretario, gestión de conflictos, aseguramiento de calidad, marketing, gestión de pilotos.

Tareas a realizar para la siguiente semana

• Abrir con elevator pitch bien estructurado.
• Explicar claramente el tipo de negocio.
• Refinar análisis de competidores.
• Análisis de costes con TCO: personal, amortización, costes de apoyo y licencias, costes de mantenimiento e indirectos.
• Gestión de usuarios pilotos, asegurando coherencia con la píldora teórica.
• MVP: Mockups más específicos con los casos de uso del Sprint 1.
• Innovación y diferenciación clara.
• Gestión de riesgos detallada.
• Stack tecnológico definido.
• Refinar equipo: imagen corporativa y estructura de roles con responsabilidades justificadas.
• Commitment agreement actualizado.
• Plan de gestión de calidad del desarrollo: modelo de análisis, medición y solución de problemas.
• Modelo de rendimiento del equipo: evaluación cuantitativa semanal.
• ALM: Uso obligatorio de GitHub, GitHub Actions y GitHub Projects. Integración y despliegue continuo con Clockify.
• Definir gestión del código: etiquetado, ramas, versionado y política de gestión.
• Landing page con idea clave y email de contacto. URL a la landing page con enlaces a despliegues.
• Planificación: estimación de los 3 sprints, división de casos de uso y asignación de responsabilidades.
• Report de IA.

Semana 3

Feedback relacionado con la presentación

• Diseño de diapositivas:
  • No usar "10.000", sino "10k" en las cifras.
  • En general el diseño ha gustado.
• Estructura de la presentación:
  • Elevator pitch más corto.
  • No detenerse demasiado en la diapositiva 2 (tipo de negocio, innovación, cliente-usuario).
• Forma de presentar:
  • Mejorar la vocalización siguiendo el video de Julian Treasure.
  • Es recomendable grabarse para medir tiempos y mejorar la vocalización.
  • Preparar un speech de emergencia en caso de que el tiempo se alargue.
  • Se ha quedado un poco corta la presentación.
  • Hablar más tiempo de competidores.

Feedback relacionado con el desarrollo del proyecto

• Gestión de usuarios pilotos:
  • Pocos usuarios pilotos (20).
  • Diferenciar entre "Usuarios Pilotos" y "Pilotos Usuarios".
  • Plan de comunicación y beneficio no deben mezclarse con la gestión de usuarios pilotos.
• Mockups y prototipos:
  • Mockups demasiado básicos, evitar incluir comentarios innecesarios.
• Gestión de riesgos:
  • Identificar opciones de mitigación para evitar que los riesgos se conviertan en problemas reales antes de que ocurran.
• MVP y Casos de Uso:
  • Sprint 1 debe centrarse en los casos de uso core, no en el MVP.

Tareas a realizar para la siguiente semana

1. Introducción (15-20%)
2. Killer opener
3. Elevator pitch
4. Resumen de competidores con la tabla
5. Resumen de análisis de costes
6. El equipo: responsabilidades y evaluación de compromiso.
7. Prototipo: mostrar un pequeño prototipo claro y conciso.
8. Retrospectiva de mitad de sprint:
   • Análisis de calidad del desarrollo.
   • Evaluación de rendimiento del equipo (horas, productividad, medición).
   • Problemas encontrados, trazabilidad con los riesgos y su estatus.
   • Lecciones aprendidas.
9. Reloj de avance del proyecto: comparación entre el tiempo invertido y el esperado.
10. Planificación (15-20%):
    • Replanificación si es necesario.
    • Objetivos finales del Sprint 1.
    • Posibles efectos en los siguientes sprints.
11. Gestión de usuarios pilotos (10%):
    • Cuántos usuarios hay y de qué tipo.
    • Agenda para trabajar con ellos.
    • Facilitar el feedback mediante plantillas.
    • Plan de acción para el siguiente sprint.
12. Uso de la IA.

Semana 4

Feedback relacionado con la presentación

• Diseño de diapositivas
  • Demasiadas transparencias para la presentación del equipo.
  • En la diapositiva 22, se habló demasiado con poco apoyo visual.
• Estructura de la presentación
  • Explicar mejor las ventajas de la aplicación frente a los competidores durante la presentación.
• Forma de presentar
  • El killer opening debe conectar directamente con el proyecto.
  • Faltó presentarse al inicio de la presentación.

Feedback relacionado con el desarrollo del proyecto

• Gestión de usuarios pilotos
  • Es necesario clarificar la comunicación con los usuarios pilotos: cuándo se contactará con ellos, el tiempo que se les dará, la metodología y la agenda de trabajo.
• Métricas y productividad del equipo
  • La productividad del equipo se queda corta. Se sugiere añadir más métricas, no solo cuantitativas (commits, horas), sino también cualitativas, para evitar el efecto cobra.
  • Incluir criterios cualitativos que reflejen mejor el trabajo del equipo.
• Planificación y seguimiento
  • Hacer una comparativa clara entre lo planificado inicialmente y los cambios realizados durante el desarrollo.
• Mockups y prototipos
  • Considerar grabar la demo en lugar de hacerla en vivo, ya que puede ser más efectiva.
  • No es relevante incluir elementos genéricos como el registro.

Tareas a realizar para la siguiente semana

1. Killer opener
   • Máximo un minuto.
   • Debe conectar directamente con el proyecto y captar la atención del público desde el inicio.
2. Elevator pitch
   • Duración: 30-45 segundos.
   • Resumen claro y conciso del proyecto, su valor diferencial y las ventajas clave frente a los competidores.
3. Resumen de competidores con la tabla
   • Incluir un resumen del análisis de competidores.
   • Mostrar una tabla comparativa destacando las ventajas de nuestra aplicación frente a los competidores.
4. Resumen de análisis de costes
   • Desglosar el análisis de costes en TCO, CapEx y OpEx.
   • No entrar en detalles excesivos, pero incluir aspectos clave:
     • Situación actual respecto al total esperado.
     • Estimaciones a 4-6 meses y 1-2 años de gastos e ingresos.
     • Justificar los ingresos y mostrar las tres curvas: pesimista, esperada y optimista.
5. El equipo: responsabilidades y miembros.
   • Máximo 2 minutos.
   • Resumen de las responsabilidades de cada miembro.
6. Prototipo: mostrar un pequeño prototipo claro y conciso.
   • Presentar los casos de uso CORE de forma dinámica (15% de la presentación).
   • Asegurarse de que sea clara y fácil de entender.
7. Retrospectiva:
   • Análisis de calidad del desarrollo.
   • Evaluación de rendimiento del equipo (horas, productividad, medición).
   • Al menos una transparencia de rendimiento de cada miembro del equipo.
   • Problemas encontrados, trazabilidad con los riesgos y su estatus.
   • Lecciones aprendidas.
8. Reloj de avance del proyecto: comparación entre el tiempo invertido y el esperado.
   • Comparar el tiempo invertido hasta ahora con lo planificado inicialmente.
   • Mostrar el progreso del proyecto en relación con los objetivos establecidos.
9. Planificación:
   • Planificación del Sprint 2.
   • Replanificaciones.
   • Posibles efectos en los siguientes sprints.
10. Gestión de usuarios pilotos (10%):
    • Cuántos usuarios hay y de qué tipo.
    • Agenda para trabajar con ellos, tiempos para que respondan, cómo vamos a gestionar su feedback.
    • Plan de acción para el siguiente sprint.
11. Uso de la IA.
    • Reporte sobre el uso de la IA.
    • Incluir información sobre posibles "alucinaciones" y cómo se han manejado.
12. Landing page.

Semana 5

Feedback relacionado con la presentación

• Métricas de rendimiento: Buen uso de métricas para evaluar el desempeño del equipo.
• Marketing: Se debe tener en cuenta que los clientes principales son las empresas.
• Resolución de problemas: El planteamiento de los problemas que han surgido y especialmente la resolución de estos ha sido valorada positivamente, como el asignar obligatoriamente a miembros para revisar PRs para evitar sobrecargar a los coordinadores.
• Iconos de roles: Los iconos para distinguir el rol de camionero y el de empresa de la demo han gustado y sería buena idea que los iconos / roles estuviesen también presentes en el killer opener.

Feedback relacionado con el desarrollo del proyecto

• Resolución de problemas: Se ha valorado positivamente la automatización en la resolución de problemas.
• Métricas automatizadas: Se ha valorado positivamente el uso de herramientas que permitan obtener métricas automatizadas, se recomienda seguir en esta línea e incluso ampliar su uso.
• CapEx y OpEx: Se ha cometido un error al invertir los conceptos de CapEx y OpEx. Es importante corregirlo en futuros análisis financieros.
• Desglose financiero: Es necesario desglosar mejor CapEx y OpEx para mayor claridad en los costes de desarrollo y operación.

Tareas a realizar para la siguiente semana

1. Refinamiento del killer opener (máximo 1 minuto).
2. Elevator pitch: Debe enlazar de manera fluida con el killer opener.
3. Análisis de competidores: Revisión y actualización del análisis competitivo.
4. Storyboard de un anuncio futuro:
   • Definir tres tipos de destinatarios: usuario, cliente y/o inversores (cifras y datos).
   • No es necesario producir el anuncio, solo conceptualizarlo e incluirlo en la presentación.
5. Implicaciones legales:
   • Considerar GDPR, tratamiento de datos personales y licencias.
   • Incluir un checkbox de términos y condiciones en el registro.
   • Definir un nuevo rol en el equipo para la administración de GDPR.
6. TCO:
   • CapEx (Gasto capitalizado): Elementos comprados que forman parte de la empresa (servidores, ordenadores).
   • OpEx (Coste operativo): Costes de desarrollo y mantenimiento, no capitalizables (ejemplo: servicios en la nube).
7. Demo de mid-sprint 2:
   • Presentar los avances reales del sprint.
   • Incluir datos reales y evitar placeholders genéricos.
8. Refinamiento de datos:
   • Incluir nombres de empresas y ofertas reales en las presentaciones para mayor autenticidad.
9. Retrospectiva:
   • Evaluación de métricas de rendimiento y mejoras en el desarrollo.
10. Gestión de usuarios pilotos:
    • Refinar la estrategia de gestión de usuarios pilotos y la recolección de feedback.
11. Planificación y reestimación del Sprint 2 en caso necesario.
12. Implementación de pagos reales en modo sandbox.
13. Uso de IA:
    • Incluir métricas sobre su efectividad y posibles mejoras en su implementación.
14. Actualización de la landing page con información relevante y refinada.

Semana 6

Feedback relacionado con la presentación

• Ritmo de la presentación: Se percibió un ritmo algo rápido en las primeras diapositivas, lo cual puede atribuirse a los nervios iniciales. Ajustar el ritmo al comienzo podría mejorar la atención del público. Se destacó un buen inicio de presentación.
• Storyboard y target: Faltó incluir información sobre los usuarios finales en el storyboard. Es recomendable desarrollar un storyboard específico para cada objetivo, centrado en un target claramente definido, en lugar de uno general que no clarifique su audiencia. El storyboard dirigido a inversores no resultó convincente, ya que no se mencionó el retorno de inversión esperado. Esto es crucial para captar su interés.
• Estrategia de comunicación: Se plantea como un problema potencial que los camioneros, uno de los públicos objetivo, no ven la televisión regularmente, lo que podría limitar el alcance del anuncio. Se sugiere enfocar más esfuerzos hacia los inversores como audiencia clave.
• Killer opener: debe estar más conectado con la demo. Relacionar ambos elementos de manera coherente ayudará a mantener la atención y reforzar el mensaje central. La idea del killer opener utilizando la alarma fue valorada positivamente. Sin embargo, debe integrarse mejor con la demo.
• Uso del lenguaje: Evitar expresiones como "cuánto costamos" y corregir términos como "competición" (en lugar de "competidores") para mejorar la precisión del lenguaje.
• Apoyo visual: Muchas ideas importantes se explicaron sin apoyo visual, como ocurrió al comentar el feedback y los cambios realizados tras las pruebas con usuarios piloto. Incorporar gráficos o esquemas visuales mejoraría la comprensión. En la diapositiva final, sería útil incluir el correo electrónico de contacto para facilitar la interacción posterior.
• Demostración: La demo podría beneficiarse de contar con varias voces y establecer una conexión más clara con el killer opener para evitar la monotonía y mejorar la experiencia auditiva. La calidad de audio y video de la demo fue deficiente, lo que afectó la percepción general. Se recomienda mejorar tanto la grabación como la edición.
• Aspectos técnicos: Los problemas detectados no solo se relacionan con errores de código, sino también con aspectos de coordinación y gestión del equipo. Esto debe ser abordado en futuras iteraciones.
• Gestión del tiempo: En el reloj de avance del proyecto, se observó que algunas tareas tardaron más de lo esperado en cerrarse. Se sugiere reconsiderar los puntos de historia para distribuir mejor el trabajo y cerrar tareas de forma más progresiva.

Feedback relacionado con el desarrollo del proyecto

• Tratamiento de usuarios: Las explicaciones sobre el tratamiento de los usuarios fueron claras y bien estructuradas.
• Clasificación del feedback: No se explicó cómo se clasificó y priorizó el feedback recibido de los usuarios piloto. Documentar este proceso permitirá justificar las decisiones tomadas y mejorar la transparencia.
• Análisis financiero: Se recomienda crear una tabla que combine los datos de costes/gastos con los beneficios esperados, lo que facilitará una visión integral de la viabilidad económica del proyecto.

Tareas a realizar para la siguiente semana

1. Refinamiento del killer opener (máximo 1 minuto).
   • Asegurarse de que esté conectado con la demo y refleje claramente el propósito del proyecto.
2. Elevator pitch (30 segundos).
   • Debe ser conciso, impactante y enlazar fluidamente con el killer opener.
3. Análisis de competidores:
   • Revisar y actualizar el análisis competitivo, destacando las diferencias clave con respecto a la competencia.
4. Storyboard de un anuncio futuro:
   • Enfocar el storyboard hacia un target específico: usuario, cliente o inversores.
   • Seguir las píldoras teóricas sobre storyboards y evitar enfocarlo en inversores.
   • Conceptualizar el anuncio sin necesidad de producirlo, centrándose en la narrativa y los elementos clave.
5. Customer agreement:
   • Definir los términos y condiciones del servicio, prestando especial atención a:
     • Cláusulas abusivas.
     • Pricing y SLA (Acuerdos de Nivel de Servicio).
     • Implicaciones legales relacionadas con APIs de terceros u otros aspectos que deban incluirse en los términos.
6. TCO (Total Cost of Ownership):
   • Refinar el análisis de costes:
     • CapEx: Inversiones en activos duraderos (servidores, equipos, etc.).
     • OpEx: Gastos recurrentes como servicios en la nube o mantenimiento.
   • Mejorar las estimaciones basándose en los aprendizajes recientes.
7. Equipo:
   • Mantener la estructura actual de roles, asegurándose de que estén claramente definidos y asignados.
8. Commitment agreement status:
   • Evaluar si se ha cumplido con los compromisos establecidos en el acuerdo inicial.
   • Documentar cualquier desviación y las acciones tomadas para corregirla.
9. Demo:
   • Preparar una demo clara y bien estructurada que muestre los avances reales del proyecto.
   • Mejorar la calidad audiovisual y considerar el uso de varias voces para evitar la monotonía.
10. Retrospectiva del Sprint 2 (40-50% de la presentación):
    • Utilizar gráficos para analizar el rendimiento y el esfuerzo del equipo:
      • Alto rendimiento / Alto esfuerzo.
      • Alto rendimiento / Bajo esfuerzo.
      • Bajo rendimiento / Alto esfuerzo.
      • Bajo rendimiento / Bajo esfuerzo.
    • Incluir un gráfico de rendimiento del equipo y evaluar las métricas clave.
11. Resultado del análisis de software:
    • Presentar los hallazgos del análisis realizado, destacando fortalezas y áreas de mejora.
12. Problemas encontrados:
    • Detallar cada problema identificado, incluyendo:
      • Descripción del problema.
      • Solución implementada (acciones concretas).
      • Evaluación de la efectividad de la solución.
      • Estado actual del problema.
    • Extraer lecciones aprendidas para futuros sprints.
13. Reloj de avance del proyecto:
    • Analizar el progreso del proyecto utilizando el reloj de avance.
    • Reconsiderar los puntos de historia para cerrar tareas de forma más paulatina y eficiente.
14. Gestión de usuarios pilotos:
    • Refinar la estrategia de gestión de usuarios pilotos basándose en las píldoras teóricas.
    • Recopilar y analizar el feedback recibido, documentando cómo se ha clasificado y priorizado.
15. Planificación y replanificación:
    • Realizar una planificación detallada para el próximo sprint.
    • Si es necesario, ajustar la planificación actual para alinearla con los objetivos del proyecto.
16. Uso de IA:
    • Evaluar si se ha mejorado el uso de la IA desde el inicio del proyecto.
    • Documentar lecciones aprendidas, incluyendo casos de alucinaciones de la IA y cómo se han abordado.
17. Landing page y contacto:
    • Actualizar la landing page con información relevante e incluirla en la presentación.
    • Incluir el correo electrónico de contacto en la página final de la presentación para facilitar la interacción posterior.

Semana 7

Feedback relacionado con la presentación

• Impacto emocional y engagement: La presentación fue muy bien recibida en general.
• Demostración: La demo fue considerada como muy buena. Sin embargo, se sugiere ajustar el nivel de zoom en ciertas partes para mejorar la claridad visual.
• Elevator pitch y killer opener: El inicio fue efectivo y capturó rápidamente la atención del público. El killer opener estuvo bien conectado con el resto de la presentación, especialmente con el cierre (esto gustó bastante).
• Habilidad comunicativa: Ambos presentadores fueron elogiados por su habilidad para comunicar ideas de forma clara y dinámica. Cristina destacó especialmente la trazabilidad de los problemas, un aspecto que suele ser débil en otros grupos pero que aquí se manejó bastante bien.
• Conexión con el público: La capacidad del grupo para hilar cada fase de la presentación (problema, solución, beneficios) fue destacadar. Además, la conexión entre el problema de la baja laboral, el esfuerzo y el rendimiento fue particularmente efectiva.
• Feedback previo: El grupo mostró una excelente capacidad para integrar y aplicar el feedback recibido en iteraciones anteriores, lo que fue elogiado por los profesores.

Feedback relacionado con el desarrollo del proyecto

• Beneficio para empleados: Se sugiere detallar más cómo los empleados se beneficiarán semanalmente de la implementación de la solución propuesta.
• Integración de herramientas: Se recomienda explorar herramientas como Copilot para optimizar procesos técnicos, como el merge de código y la revisión automática de pull requests. Esto podría mejorar la eficiencia del equipo.
• Matriz de rendimiento: En la autoevaluación del equipo, se sugiere utilizar métricas más objetivas para medir el rendimiento, en lugar de basarse únicamente en percepciones subjetivas.

Tareas a realizar para la siguiente semana

1. Killer opener:
   • Refinar el killer opener para asegurar que conecte claramente con la demo y refleje el propósito central del proyecto.
2. Elevator pitch:
   • Preparar un elevator pitch conciso (30 segundos) que sea impactante y enlace fluidamente con el killer opener.
3. Competidores:
   • Actualizar el análisis de competidores, destacando las diferencias clave entre el proyecto y las soluciones existentes en el mercado.
4. Anuncio:
   • Crear anuncio basado en un storyboard, para un target específico (usuarios, clientes o inversores).
   • Asegurarse de que el storyboard siga las pautas teóricas y se centre en una narrativa clara.
5. Customer agreement:
   • Mantener y revisar el customer agreement, prestando especial atención a:
     • Cláusulas abusivas.
     • Pricing y SLA (Acuerdos de Nivel de Servicio).
     • Aspectos legales relacionados con APIs de terceros u otros elementos relevantes.
6. Costes:
   • Revisar y mantener el análisis de costes realizado anteriormente, asegurando que esté actualizado con los aprendizajes más recientes.
7. Equipo:
   • Mantener la estructura de roles del equipo, asegurándose de que estén claramente definidos y asignados.
   • Mencionar el commitment agreement y evaluar si se han cumplido los compromisos establecidos.
8. Demo:
   • Resaltar mejoras realizadas en la UX/UI y la implementación de regulaciones (por ejemplo, checkbox de política de datos, HTTPS, temas de privacidad).
   • Mejorar la calidad audiovisual y considerar el uso de varias voces para evitar la monotonía.
9. Retrospectiva midsprint 3:
   • Analizar la transparencia del esfuerzo-rendimiento del equipo utilizando gráficos.
   • Diseñar un plan de pruebas para antes del WPL y extraer lecciones aprendidas.
10. Problemas encontrados:
    • Documentar problemas identificados, incluyendo:
      • Acciones concretas para mitigarlos.
      • Evaluación de la efectividad de las soluciones aplicadas.
      • Métricas medibles cuantitativamente y objetivos claros para futuras mejoras.
11. Reloj de avance:
    • Analizar el progreso del proyecto utilizando el reloj de avance.
12. Plan de usuarios pilotos:
    • Refinar la estrategia de gestión de usuarios pilotos.
    • Categorizar y priorizar el feedback recibido mediante un ranking claro.
13. Planificación para la siguiente semana:
    • Considerar replanificaciones o recortes en el alcance si es necesario para alinear con los objetivos del proyecto.
14. Planning preliminar del PPL:
    • Orientar el planning hacia anuncios y publicidad.
    • Diseñar una campaña de lanzamiento y refinamiento del MVP.
15. Uso de IA:
    • Evaluar y documentar el uso de IA en el proyecto, incluyendo casos de alucinaciones y cómo se han abordado.
16. Landing page y contacto:
    • Actualizar la landing page con información relevante e incluirla en la presentación.
    • Incluir el correo electrónico de contacto en la página final de la presentación para facilitar la interacción posterior.

Semana 8

Feedback relacionado con la presentación

• Claridad en la demo: La demo fue percibida como demasiado rápida y poco clara en cuanto a su propósito. No quedó claro si se trataba de un anuncio o una demo, ya que no se especificó previamente. Se sugiere incluir una breve introducción antes de la demo para contextualizar su objetivo.
• Uso de suposiciones: Evitar términos como "suposición" y reemplazarlos por palabras más precisas como "estimaciones" o frases del tipo "De acuerdo al informe X..." para transmitir mayor rigor.
• Equilibrio entre texto y gráficos: En algunas diapositivas (por ejemplo, la diapositiva 3), se notó un exceso de texto. Es recomendable reducir el texto y balancearlo con recursos gráficos para mejorar la claridad y el impacto visual.
• Gráficos de rendimiento: Los indicadores de rendimiento actuales (como el gráfico estilo velocímetro) no son los más adecuados para entender el estado del proyecto. Se sugiere utilizar gráficos más efectivos, organizados por áreas o mediante otros tipos de diagramas que faciliten la interpretación.
• Categorización del feedback: En la diapositiva de categorización del feedback, añadir porcentajes para cada tipo de feedback recibido.

Feedback relacionado con el desarrollo del proyecto

• Evidencia de análisis de problemas: Mostrar evidencia clara del análisis realizado sobre los problemas identificados. Esto puede incluir datos, gráficos o ejemplos concretos que respalden las conclusiones.
• Claridad en la resolución de problemas: Añadir más texto explicativo a los problemas resueltos para evitar confusiones. Se sugiere estructurar esta información en un formato claro: Problema → Solución → Objetivos → Periodo → Trazabilidad.
• Mejora en la retrospectiva del proyecto:
  • Indicadores de rendimiento: Revisar los indicadores actuales, ya que no reflejan adecuadamente el estado del proyecto. Proponer alternativas más efectivas para visualizar el progreso.
  • Objetivos y periodos: Incluir objetivos claros y periodos específicos para contextualizar mejor el estado del proyecto. Esto permitirá evaluar si las soluciones implementadas están funcionando según lo planeado.
  • Posibles mejoras: Además de listar problemas, plantear posibles mejoras futuras que puedan optimizar el proyecto.
• Métricas en perspectiva: Incluir el número de métricas analizadas, pero siempre en contexto. Mostrar tendencias claras: de dónde venimos, dónde estamos y hacia dónde vamos. Esto ayudará a visualizar el progreso de manera más efectiva.
• Gestión del feedback: Mejorar la presentación del feedback recibido mediante gráficos más claros y una categorización más detallada. Asegurarse de que las métricas estén en perspectiva para destacar la evolución del proyecto.

Tareas a realizar para la siguiente semana

1. Elevator pitch:
   • Preparar un elevator pitch conciso (30 segundos) que sea impactante y refleje claramente el propósito del proyecto.
2. Competidores:
   • Actualizar el análisis de competidores, destacando las diferencias clave entre el proyecto y las soluciones existentes en el mercado.
3. Anuncio en video:
   • Crear un anuncio en video diferente al anterior, enfocado a otro target audience (como inversores).
   • Asegurarse de que el anuncio sea atractivo y transmita claramente el valor del proyecto para este público objetivo.
4. Tareas de marketing preliminares:
   • Gestionar la tracción inicial en el mercado mediante acciones en redes sociales y otras actividades de marketing.
   • Desarrollar estrategias para ganar clientes potenciales.
5. New roles relacionados con marketing:
   • Incorporar roles nuevos relacionados con la gestión del equipo de marketing, como Community Manager u otros perfiles necesarios para cubrir las necesidades del proyecto.
   • Asegurarse de que estos roles estén claramente definidos y asignados.
6. Costes:
   • Mantener el análisis de costes similar a las últimas semanas, incluyendo:
     • Previsión de gastos (CapEx y OpEx).
     • Puntos de corte y estimaciones realistas.
   • Incluir los gastos asociados a los nuevos roles (por ejemplo, Community Manager) y resaltar los costes de marketing (publicidad, etc.).
7. Equipo refinado con roles nuevos:
   • Refinar la estructura del equipo incorporando los nuevos roles relacionados con marketing.
   • Asegurarse de que todos los roles estén claramente definidos y asignados.
8. Demo S3:
   • Incluir una breve introducción antes de la demo explicando de qué trata y si es general o específica para ciertos usuarios.
   • Utilizar datos e historias realistas, destacando la experiencia del usuario (UX) y la conformidad con el GDPR.
   • Resaltar con iconos los diferentes tipos de usuarios involucrados.
9. Retrospectiva S3:
   • Analizar el rendimiento del equipo utilizando una matriz de rendimiento-esfuerzo.
   • Incluir una diapositiva que muestre el rendimiento individual de cada miembro del equipo.
   • Refinar el plan de pruebas si ya existía uno previamente.
   • Realizar un análisis de código detallado.
10. Problemas encontrados:
    • Documentar problemas identificados, incluyendo:
      • Métricas cuantificables para evaluar el progreso.
      • Objetivos claros para resolverlos.
      • Estado actual de las soluciones implementadas.
    • Analizar el reloj de avance del proyecto para evaluar el progreso global.
11. Plan de gestión de usuarios pilotos:
    • Enfocar el plan en la recopilación, clasificación y priorización del feedback recibido.
    • Destacar cómo se utilizará este feedback para mejorar el proyecto.
12. Planificación de cara a lo siguiente:
    • Reestimar el desarrollo si es necesario, ajustando el alcance o replanificando tareas para alinearse con los objetivos del proyecto.
13. Planificación de PPL:
    • Desarrollar un plan preliminar para el PPL, enfocado en anuncios y publicidad.
    • Diseñar una campaña de lanzamiento y refinamiento del MVP.
14. Reporte de IA:
    • Documentar el uso de IA en el proyecto, incluyendo casos de alucinaciones y cómo se han abordado.
15. Diapositiva final con información de contacto y QR:
    • Crear una diapositiva final que incluya información de contacto y un QR para facilitar la interacción posterior.

Semana 9

Feedback relacionado con la presentación

• Tono de la demo: La demo debe adoptar un tono más formal. Se sugiere ajustar el modelo actual para reducir la informalidad.
• Claridad de la voz: La voz de las presentadoras no se escuchaba bien. Se recomienda plantear el uso de micrófonos o mejorar la calidad del sonido durante la presentación.
• Valor para el usuario en la demo: La demo debería centrarse más en lo que aporta valor al usuario. Además, debe mostrar todas las funcionalidades clave de forma clara y completa.
• Consulta a usuarios pilotos sobre la demo: Considerar preguntar a los usuarios pilotos su opinión sobre la demo para identificar áreas de mejora desde la perspectiva del usuario final.

Feedback relacionado con el desarrollo del proyecto

• Hilación de cambios: Se valoró positivamente que se hayan tenido en cuenta los comentarios de la semana pasada y que los cambios estén bien hilados en la presentación.
• Anuncio inicial: El anuncio inicial fue destacado como efectivo, ya que va directo al grano y capta la atención del público al transmitir claramente el mensaje y el valor de la plataforma.
• Datos sobre clientes y transportistas: Es necesario incluir datos concretos (no porcentajes) sobre el número de clientes o transportistas que se espera alcanzar en diferentes puntos temporales. Por ejemplo: ¿cuántos transportistas habrá en X años?
• Apartado de inversión: El apartado de inversión no fue percibido con suficiente detalle. Se sugiere profundizar en este aspecto para ofrecer una visión más clara y convincente a los inversores.

Tareas a realizar para la siguiente semana

1. Ensayo del World Project Launch (10 min)
Una buena presentación debe responder a las siguientes preguntas:

1. ¿De qué va el proyecto?
   • Puede ser un killer opener o un anuncio corto de máximo un minuto.
2. ¿Qué hace exactamente?
   • Demostración, enlazada con una historia (si puede estar conectada al anuncio, mejor).
   • ¿Y cómo lo hace?
3. ¿Cómo nos diferenciamos de la competencia?
   • Comentar los factores clave que nos hacen únicos frente a la competencia.
4. ¿Quién hay detrás de esto?
   • Presentar al equipo.
5. ¿Puede llegar a ser rentable?
   • Puntos clave del mercado, planes de negocio, costos a corto y medio plazo, oportunidades de inmersión.
   • Ejemplo: incluir un vídeo de anuncio.
6. ¿Dónde puedo encontrar más información?

2. Algo más específico del PPL (5 min)
Estas son sugerencias; podemos decidir qué incluir o no en la presentación:

1. Marketing para ganar más mercado
   • Segmentación de los usuarios.
2. Usuarios potenciales, tipo de usuario/tipo de cliente
   • Concepto de persona: caracterización de un cliente ficticio como una historia que sitúe al usuario.
   • Crear un par de personas para entender las necesidades de los clientes y usuarios.
   • Referencia: Persona (Wikipedia).
3. SEO
   • Palabras clave: ¿cuáles serían las nuestras?
4. Campaña de lanzamiento del producto
   • Promociones y acciones para impulsar la tracción inicial.
5. Crecimiento de la comunidad inicial
   • Partners potenciales e impacto mediático.
6. Community management
   • Objetivos, plan y roles.
   • Nivel de detalle según decisión interna.
7. Costes del marketing.
8. Anuncios
   • No es necesario repetir anuncios si ya se incluyeron en otra presentación.

Semana 10

Feedback relacionado con la presentación

• Claridad visual y técnica:
  • Se recomienda apagar la luz frontal para mejorar el contraste visual.
  • La demo se veía regular; se sugiere revisar iluminación o aplicar más zoom.
• Distribución del contenido:
  • En el anuncio de usuarios, se justificó el plan premium muy brevemente, solo se sentía como si se justificara su compra por el precio.
  • La diapositiva sobre funcionalidades se hizo pesada. Se sugiere explicar rápido y dejar que se entienda en la demo.
  • Hay repetición innecesaria del modelo de negocio y planes de precios antes y durante el anuncio para inversores. Se recomienda reorganizar para evitar redundancia.
  • La duración actual necesita recortes para incluir todo el contenido necesario en la presentación final del WPL.
• Contenido de la demo y anuncios:
  • Buena presentación general y enfoque claro de la demo.
  • Gustó mucho el anuncio para inversores y cómo se estructuró.
  • El anuncio de usuarios fue valorado positivamente, aunque se percibió un poco largo; acortarlo puede beneficiar.
  • En el video de artículos, fue positivo que se mostraran claramente las fuentes.
• Contenido de marketing (PPL):
  • Faltan detalles de community management: objetivos, plan, roles, y cómo se gestionarán las redes sociales.
  • Se recomienda incluir el cronograma de publicaciones y detallar si se usarán banners en webs u otros canales externos.
  • El plan de difusión de anuncios debe desarrollarse más (anuncios, banners, fechas, invitaciones a influencers, etc.).
  • Faltan objetivos claros para la campaña de marketing y un plan de referidos con plazos y metas definidas.

Feedback relacionado con el desarrollo del proyecto

• Enfoque estratégico:
  • Les gusta cómo se está presentando el proyecto y su enfoque general.
  • El anuncio inicial fue bien valorado, al igual que la explicación de los planes de inversión.
• Datos financieros y de crecimiento:
  • Faltan datos de costes concretos y gráficas explicativas.
  • Es necesario incluir estimaciones financieras claras y objetivos específicos de marketing.
  • Al final de la presentación debe definirse una de las dos ofertas como prioritaria.

Tareas a realizar para la siguiente semana

1. Ensayo del World Project Launch (10 min)
Una buena presentación debe responder a las siguientes preguntas:

1. ¿De qué va el proyecto?
   • Puede ser un killer opener o aprovechar con demo o anuncio corto de máximo un minuto.
2. Anuncio
   • Anuncio de inversores, se hizo hincapié en que apareciera en la primera presentación.
3. ¿Cómo nos diferenciamos de la competencia?
   • Comentar los factores clave que nos hacen únicos frente a la competencia.
4. ¿Quién hay detrás de esto?
   • Presentar al equipo.
5. ¿Puede llegar a ser rentable?
   • Puntos clave del mercado, planes de negocio, costos a corto y medio plazo, oportunidades de inmersión.
   • Ejemplo: incluir un vídeo de anuncio.
6. ¿Dónde puedo encontrar más información?
   • Landing page, correo y como contactarnos.

2. Algo más específico del PPL (5 min)

1. Marketing para ganar más mercado
   • Modelo de segmentación de los usuarios (se recomienda ver la píldora teórica).
2. Usuarios potenciales, tipo de usuario/tipo de cliente
   • Concepto de persona: caracterización de un cliente ficticio como una historia que sitúe al usuario.
   • Crear un par de personas para entender las necesidades de los clientes y usuarios.
3. SEO
   • Palabras clave: ¿cuáles serían las nuestras?
4. Campaña de lanzamiento del producto
   • Promociones y acciones para impulsar la tracción inicial.
   • Partners potenciales e impacto mediático.
5. Community management
   • Objetivos, plan y roles.
   • Nivel de detalle según decisión interna.
6. Costes del marketing.
7. Anuncios
   • Videos, banners y demás material promocional.

Semana 11

Feedback relacionado con la presentación

• Inicio y dinámica general:
  • El inicio de la presentación fue efectivo y captó bien la atención.
  • Pablo considera que el ritmo de la presentación es adecuado.
• Claridad visual y técnica:
  • Las capturas de pantalla después de la demo fueron bien valoradas por Cristina, aunque Pablo las encuentra redundantes.
  • Se recomienda revisar la calidad de las capturas de pantalla, ya que no se ven claramente.
  • La letra en los paquetes de inversión no se ve demasiado bien; se sugiere mejorar su visibilidad.
  • Evitar el uso técnico como "CapEx" u "OpEx", para que sea más accesible a todo el público.
  • En lugar de hablar de frontend o backend, se propone un enfoque más general del equipo, como subgrupos o roles destacados.
• Demostración:
  • A Cristina le gustó la demo, pero a Pablo no.
  • A Pablo no le gustó la coloquialidad empleada durante la demo.
  • Se recomienda transmitir seguridad mostrando lo ya implementado, evitando hablar siempre en futuro ("tenemos" en vez de "tendremos").
• Estructura y contenido:
  • El cambio en el anuncio fue bien recibido.
  • Se recomienda hacer la introducción más llamativa y atractiva.
  • Hay momentos en los que se habla en futuro cuando debería proyectarse confianza mostrando logros concretos.
• Contenido de marketing (PPL):
  • Muy bien explicada la segmentación del mercado, especialmente las dos franjas iniciales.
  • Gustó mucho el calendario de publicaciones en redes sociales con los tipos de contenido definidos.

Feedback relacionado con el desarrollo del proyecto

Este apartado se encuentra en blanco ya que no se han proporcionado observaciones específicas sobre el desarrollo técnico del proyecto en esta fase.

Tareas a realizar para la siguiente semana

Este apartado se encuentra en blanco ya que no se han definido tareas concretas para la próxima semana en esta revisión.

Otros Grupos

Semana 1

Feedback relacionado con la presentación

• Diseño de diapositivas:
  • Se ha identificado un problema recurrente en el diseño de las diapositivas.
• Estructura de la presentación:
  • Presentar primero la idea, luego el equipo.
  • Evitar expresiones que muestren inseguridad (quizás, tal vez, puede ser).
  • Numerar las diapositivas para facilitar el feedback.
  • Evitar ver las presentaciones como un guion.
  • Si hay mockups, asegurarse de que se alineen con el estilo de la presentación.

Feedback relacionado con el desarrollo del proyecto

• Idea clave: Refinar el business statement y dejar claro qué problema se está resolviendo.
• Competidores: Se ha identificado como un problema recurrente la falta de análisis de competidores y diferenciación.
• Imagen corporativa: Se ha señalado la importancia de definir una imagen corporativa.
• Vocabulario:
  • Evitar vocabulario demasiado específico de ISPP.
  • Evitar términos excesivamente técnicos o específicos sin explicación.
• Planificación y cumplimiento de tareas:
  • No adelantarse a tareas que no se han solicitado aún.

Semana 2

Feedback relacionado con la presentación

• Diseño de diapositivas:
  • Se ha identificado un problema recurrente en el diseño de las diapositivas.
• Estructura de la presentación:
  • Presentar a los presentadores.
  • Saltar el índice para no perder tiempo.
  • Iniciar destacando lo positivo.
  • Evitar usar expresiones como: sé que no se ve bien.
  • Evitar decir cosas superfluas.
  • Llevar un buen ritmo de velocidad en la presentación.
  • Enlazar bien cada punto, de competidores a MVP.

Feedback relacionado con el desarrollo del proyecto

• Análisis DAFO:
  • Que el DAFO no sea solo riesgos.
  • Analizar amenazas o problemas reales, no solo riesgos.
  • Ir a puntos específicos y concretos.
• Análisis de Coste:
  • Estimación realista de los costes de marketing.
  • No asumir que GitHub es gratuito.
  • Redondear costes.
• Análisis de Riesgos:
  • Detallar mejor algunos riesgos.
  • Clasificar los riesgos según prioridad.
• Usuarios Pilotos:
  • Ratio de respuestas de encuestas enviadas vs. recibidas.
  • Considerar seriamente las respuestas recibidas.

Semana 3

Grupo 1 (Holos)

Feedback relacionado con la presentación

• N/A.

Feedback relacionado con el desarrollo del proyecto

• Modelo de negocio:
  • Se recomienda reconsiderar la estrategia de precios fijos en los planes iniciales, ya que pueden representar una barrera para la adopción de la aplicación.
• Gestión de usuarios pilotos:
  • Se sugiere ampliar el abanico de usuarios pilotos para la próxima semana.

Grupo 2 (GastroStock)

Feedback relacionado con la presentación

• No se incluyeron números de página en la presentación.

Feedback relacionado con el desarrollo del proyecto

• Gestión de usuarios pilotos:
  • Se cuenta con un buen número de usuarios pilotos (15).
  • No se presentó un plan de gestión de usuarios pilotos.
• Análisis de competidores:
  • Falta una tabla comparativa con los competidores existentes en el mercado.
• Despliegue de la plataforma:
  • No se cuenta con una landing page desplegada.

Grupo 3 (Eventbride)

Feedback relacionado con la presentación

• El tono de la exposición fue monótono y no generó suficiente engagement.
• El elevator pitch no fue acertado.
• La diapositiva de casos de uso central no aportaba valor, considerando que ya se contaba con mockups.
• Los mockups no deberían ubicarse al final de la presentación.

Feedback relacionado con el desarrollo del proyecto

• IA:
  • Explicar mejor las conclusiones obtenidas a partir del reporte de IA.
• Gestión de riesgos:
  • Se pasó muy rápidamente por la sección de riesgos. Se recomienda una explicación más detallada.
• Métricas de encuestas:
  • Se sugiere incluir el ratio de respuestas obtenidas en comparación con las enviadas.

Grupo 4 (Borroo)

Feedback relacionado con la presentación

• El killer opening resulta poco atractivo. Evitar repeticiones excesivas para no perder impacto.
• La landing page debería presentarse preferiblemente al final de la exposición.

Feedback relacionado con el desarrollo del proyecto

• Casos de uso:
  • La lista de objetos es demasiado simple para ser el uso central de la aplicación.
• Análisis de competidores:
  • Se recomienda priorizar los aspectos que los diferencian de la competencia en la presentación.
• Planificación:
  • La distribución de casos dentro del sprint no es adecuada.
  • Poner los planes de suscripción en el último sprint no le parece adecuado.
• Costes y precios:
  • Se han detectado errores en los precios mostrados en los mockups.
  • El desglose de precios carece de suficiente información.

Grupo 6 (FisioFind)

Feedback relacionado con la presentación

• Algunos iconos utilizados no tenían un significado claro.
• Evitar hacer demasiadas referencias a la semana pasada, salvo menciones puntuales al feedback recibido.

Feedback relacionado con el desarrollo del proyecto

• Gestión de usuarios pilotos:
  • Se considera que hay pocos usuarios pilotos, se recomienda contar con al menos 10.
• Gestión de riesgos:
  • Es necesario detallar los riesgos, incluyendo su priorización, probabilidad de ocurrencia y acciones de mitigación.
• Costes:
  • La herramienta utilizada es adecuada, pero se debe mostrar un desglose claro de los costes.
• Equipo de trabajo:
  • Faltan roles y responsabilidades definidas para cada persona del equipo.
• Planificación:
  • En Sprint 1, es necesario asociar tareas con responsabilidades específicas.

Semana 4

Grupo 1 (Holos)

Feedback relacionado con la presentación

• Estructura de la presentación:
  • No empezar con las lecciones aprendidas. Reorganizar la estructura para que sea más coherente.
  • El inicio debe ser efectivo y estar directamente relacionado con la aplicación.
• Forma de presentar:
  • Pensar en cómo contar la demo correctamente. Debe tener una historia detrás que incluya los roles involucrados y cómo interactúan.
  • Feedback genérico sobre mejorar la forma de presentar (vocalización, ritmo, conexión con el público, etc.).

Feedback relacionado con el desarrollo del proyecto

• Análisis de costes y rentabilidad:
  • Desglosar los costes en CapEx y OpEx.
  • Incluir un análisis de rentabilidad en función del volumen de mercado, penetración de mercado y cuánto se espera captar.

Grupo 2 (GastroStock)

Feedback relacionado con la presentación

• El equipo no tuvo tiempo de recibir feedback.

Feedback relacionado con el desarrollo del proyecto

• El equipo no tuvo tiempo de recibir feedback.

Grupo 3 (Eventbride)

Feedback relacionado con la presentación

• Estructura de la presentación:
  • Aunque el inicio fue efectivo y fácil de relacionar con la aplicación, el final del inicio fue percibido como poco profesional.
  • La diapositiva de lecciones aprendidas gustó, pero debe incluirse en la parte de retrospectiva para mayor coherencia.
  • No mezclar la presentación del equipo con el rendimiento global del equipo; mantenerlas como secciones separadas.
• Forma de presentar:
  • Hablan muy rápido.
  • Mejorar la visualización de las diapositivas: evitar letra pequeña, reducir la cantidad de información y usar metáforas visuales para transmitir ideas de forma más efectiva.
  • Evitar términos irrelevantes como "términos y condiciones" en una demo.
  • Considerar usar "K" en lugar de "M" para cifras, aunque hay diferencias de opinión entre profesores. Podría realizarse una encuesta para decidir el formato preferido.

Feedback relacionado con el desarrollo del proyecto

• Análisis de costes y rentabilidad:
  • Desglosar los costes en CapEx y OpEx para mayor claridad.
  • Incluir un análisis de seguimiento de los problemas encontrados: especificar si están solucionados, en progreso o sin resolver.
• Gestión de usuarios pilotos:
  • En lugar de mostrar calendarios detallados, enfocarse en las fechas clave para la gestión de los usuarios piloto.

Grupo 4 (Borroo)

Feedback relacionado con la presentación

• Estructura de la presentación:
  • La tabla de competidores debe mejorarse. No quedó claro cuáles son las diferencias clave ni en qué se destacan frente a los competidores.
  • La tabla de la diapositiva número 8 no encaja con el resto de la presentación y se ve mal.
  • Faltaba un número de página en las diapositivas.
  • La demo se veía mal y había poca cantidad de contenido demostrativo. Hacer zoom en el navegador para que se vea bien desde lejos y aumentar la duración o relevancia de la demo.
• Forma de presentar:
  • Hablar muy rápido dificulta la comprensión.
  • Tener cuidado con hacer preguntas al público asumiendo cosas. Evitar suposiciones y contextualizar mejor las preguntas.
  • Reaccionar a contingencias durante la presentación, como disculparse si algo sale mal o no funciona como se esperaba.

Feedback relacionado con el desarrollo del proyecto

• Análisis de costes y rentabilidad:
  • Faltaba un plan de contingencia en los costes. Incluir cifras aproximadas sin detalles excesivos (usar "k" o "m" para simplificar).
• Gestión de riesgos y problemas:
  • Decir claramente qué problemas están resueltos y qué falta por hacer. Proporcionar más detalles sobre cómo solucionar los problemas pendientes.
  • No se hizo enlace con los riesgos. Si hay un riesgo asociado, especificar qué plan de contingencia tiene para mitigarlo.
• Rendimiento del equipo:
  • Les gusta el modelo de evaluación cualitativo (más allá de horas y commits).
  • Definir qué significa que alguien esté coordinando bien. Clarificar los criterios de evaluación del equipo.
  • Incluir algo para el análisis de calidad del código, como herramientas estilo SonarQube.
• Uso de la IA:
  • No se mencionó el porcentaje de alucinaciones de la IA ni su efectividad. Incluir datos sobre cómo de efectiva está siendo la IA en el proyecto.
• Retrospectiva:
  • Comentar más sobre los problemas encontrados, cómo se están solucionando y qué medidas se están tomando para evitar futuros problemas.

Grupo 6 (FisioFind)

Feedback relacionado con la presentación

• Estructura de la presentación:
  • El inicio efectivo fue demasiado largo y parecía más enfocado a vender fisioterapia que a conectar directamente con el proyecto. Mejorar la conexión con la aplicación.
  • Las diapositivas 9, 10 y 11 sobre costes fueron demasiado largas y difíciles de entender. Faltó claridad en las interrogaciones y ensayo en esta parte. Además, faltó incluir la moneda y traducir algunos términos al español.
  • La estructura del contenido no fue acertada, especialmente en la parte de rendimiento del equipo, ya que no era intuitiva.
  • Demasiadas transparencias en general, lo que hizo que algunas partes se pasaran muy rápido (como las diapositivas del equipo).
  • No quedó claro si los problemas mencionados eran riesgos o problemas actuales. Es importante diferenciarlos y centrarse más en el plan de acción y medición que en la probabilidad e impacto.
• Forma de presentar:
  • Algún presentador solo miraba al profesorado. Es importante mantener contacto visual con todo el público.
  • Señalar en la presentación lo que se está explicando para guiar mejor al público.
  • La demo no se podía ver correctamente porque estaba demasiado pequeña.
  • Hablar menos sobre la inversión en SEO como factor diferenciador, ya que puede no ser relevante para el mercado español.
  • La pantalla se veía amarillenta y algunas imágenes tenían mala calidad.

Feedback relacionado con el desarrollo del proyecto

• Análisis de costes y rentabilidad:
  • Aunque el desglose en CapEx y OpEx fue bueno, mejorar la claridad en la presentación de los costes para evitar confusiones.
  • Continuar con el análisis a futuro de los costes, pero asegurarse de que esté bien estructurado y sea fácil de seguir.
• Gestión de usuarios pilotos:
  • Hay un problema potencial si solo hay personas jóvenes en el grupo de usuarios pilotos, ya que el feedback podría sesgarse hacia ese grupo. Es importante incluir personas con más experiencia para obtener una perspectiva más equilibrada.
• Rendimiento del equipo:
  • En los problemas mencionados, no quedó claro si se han solucionado o no. Deben especificarse los estados de los problemas y proponer medidas de satisfacción o seguimiento.
• Uso de la IA:
  • No se mencionó nada sobre el uso de la IA. Es importante incluir datos sobre para qué se ha usado, si hubo alucinaciones, etc.

Semana 5

Grupo 1 (Holos)

Feedback relacionado con la presentación

• Se gestionó bien el plan B cuando la demo falló al intentar reproducirla.
• Es positivo que no solo se valore el rendimiento y el trabajo, sino también la satisfacción general dentro del equipo, permitiendo mejoras tanto en el ámbito laboral como interpersonal.

Feedback relacionado con el desarrollo del proyecto

• CapEx y OpEx no están bien explicados, generan confusión.
• Falta información en la estimación de costes, como el promedio de transacciones de artistas y otros detalles clave.
• La métrica de commits por sí sola no es suficiente, ya que puede ser manipulada. Se recomienda complementarla con otras métricas.
• Falta incluir el porcentaje de tareas entregadas a tiempo y detallar cómo se va a medir y mejorar.
• Se recomienda usar métricas adicionales como el cycle time y gráficas de GitHub para un mejor seguimiento del progreso.

Grupo 2 (GastroStock)

Feedback relacionado con la presentación

• Se recomienda probar las animaciones antes de presentar y tener una versión en PDF disponible como respaldo.
• Cuidado con el uso de lenguaje en la presentación.

Feedback relacionado con el desarrollo del proyecto

• Se debería dedicar más tiempo a la retrospectiva para analizar por qué se ha llegado a ciertos puntos.

Grupo 3 (Eventbride)

Feedback relacionado con la presentación

• Killer opener muy bueno, divertido y efectivo (pedida de matrimonio).
• Hacer una pausa para beber agua y revisar apuntes es una buena táctica para gestionar la exposición, pero es mejor evitar sostener la botella en la mano durante la presentación.
• Incluir un plan B en caso de que sobre tiempo al presentar. Se puede aprovechar para reforzar puntos clave si es necesario.

Feedback relacionado con el desarrollo del proyecto

• Las estimaciones no eran claras en cuanto a la base de los cálculos. Se recomienda explicitar estos fundamentos en la presentación.
• Las demos deben contar con datos más realistas.
• Los audios de los vídeos deben ser más homogéneos para evitar contrastes de sonido.
• Falta información sobre el rendimiento del equipo, como gráficas o evolución de progreso en los sprints (S1, S2).
• El procedimiento de análisis de problemas es demasiado genérico. Se recomienda especificar mejor los pasos y acciones tomadas.

Grupo 4 (Borroo)

Feedback relacionado con la presentación

• Killer opener bien trabajado y mejorado con el feedback de la semana anterior.
• Se destacó bien qué características del proyecto se estaban utilizando en cada momento.
• La demo fue bien temporizada y ejecutada, casi como si fuera en tiempo real.

Feedback relacionado con el desarrollo del proyecto

• No queda claro cómo va a evolucionar la gráfica real. La pendiente era demasiado brusca y se recomienda ajustarla para mayor realismo.
• Falta información en la parte de problemas, incluyendo medidas concretas y soluciones planteadas.
• Se ha detectado un alto nivel de alucinaciones en la IA utilizada. Es necesario analizar por qué ocurre y cómo corregir el planteamiento de la métrica de alucinación.

Grupo 6 (FisioFind)

Feedback relacionado con la presentación

• Killer opener muy profesional.
• Hablar un poco más lento para mejorar la claridad.
• La gráfica pesimista en paralelo debería ser un poco menos pesimista.

Feedback relacionado con el desarrollo del proyecto

• Muy bien resumido el análisis de rendimiento con una gráfica general que muestra toda la información.
• Más énfasis en los porcentajes de suscripciones para mayor claridad en la presentación de los datos.
• El mecanismo de quitar puntos no es intuitivo. Se sugiere utilizar términos de motivación en lugar de términos de castigo.
• No están bien identificados los riesgos en relación con los problemas detectados.

Semana 6

Grupo 1 (Holos)

Feedback relacionado con la presentación

• Introducir el tema de manera más efectiva, utilizando un hecho específico en lugar de generalidades.
• Clarificar en los costes incurridos a qué sprints corresponden (sprint 1 o sprint 2).
• Incluir una gráfica de rendimiento del equipo, incluso si los datos son anonimizados.

Feedback relacionado con el desarrollo del proyecto

• Mejorar el cumplimiento del commitment agreement, utilizando medidas cuantitativas para evaluar los problemas de forma más precisa.

Grupo 2 (GastroStock)

Feedback relacionado con la presentación

• Sin comentarios adicionales específicos.

Feedback relacionado con el desarrollo del proyecto

• Añadir datos cuantitativos para respaldar afirmaciones sobre el progreso del proyecto.

Grupo 3 (Eventbride)

Feedback relacionado con la presentación

• La demo fue muy bien recibida.
• El killer opener fue altamente valorado.
• El storyboard, realizado en estilo anuncio y dibujado, fue muy valorado.
• Buscar una herramienta para cambiar diapositivas sin tener que decir continuamente "pasa", ya que esto puede dar una mala imagen.
• No centrar el storyboard en una sola funcionalidad de la aplicación y añadir información sobre pricing al final.
• Saltarse el paso del login en la demo, ya que es básico y no aporta valor.
• No separar el análisis de problemas entre gestión y desarrollo, sino integrarlos de manera coherente.
• Mostrar las soluciones implementadas para los problemas encontrados.

Feedback relacionado con el desarrollo del proyecto

• Utilizar un diagrama de barras en lugar de otro tipo de representación para el análisis de costes.
• Destacar claramente la línea de corte de rentabilidad en los gráficos financieros.
• Incluir datos de rendimiento de todos los miembros del equipo (anonimizados) para evaluar el progreso general.

Grupo 4 (Borroo)

Feedback relacionado con la presentación

• Centrarse en aspectos específicos y relevantes, evitando generalidades que no aportan valor.

Feedback relacionado con el desarrollo del proyecto

• Centrar el storyboard en una historia concreta y un target específico.
• Revisar la asignación de calificaciones, ya que resulta extraño que todos los miembros tengan un "10".
• Proporcionar un informe más detallado sobre el uso de IA: qué herramientas se utilizaron y cómo se aplicaron.

Grupo 6 (FisioFind)

Feedback relacionado con la presentación

• El inicio fue efectivo y estuvo bien relacionado con el elevator pitch y la demo.
• Se valoró positivamente el tratamiento del tema legal relacionado con la denuncia de datos.
• El storyboard fue bien recibido.
• Dedicar menos tiempo al análisis de competidores.
• Mejorar la visibilidad de la demo, ya que los elementos mostrados eran demasiado pequeños.
• Evitar hablar sobre la demo.
• Asegurarse de que los carteles explicativos en la demo permanezcan visibles el tiempo suficiente para ser comprendidos.

Feedback relacionado con el desarrollo del proyecto

• Refactorización y tests unitarios no deben considerarse como peticiones de cambio, sino como parte del proceso habitual.
• Considerar el uso de un accumulative flow en lugar de un burn up para mostrar el progreso del proyecto.
• Revisar el sistema de recompensas gratuito, ya que podría no ser viable económicamente.

Semana 7

Grupo 1 (Holos)

Feedback relacionado con la presentación

• La demo es muy graciosa, pero resulta un poco lenta.
• El storyboard está muy bien realizado; destaca el talento artístico del grupo.
• El killer opener es bueno, pero demasiado serio y solemne.
• Falta anticipar qué se va a ver antes de reproducir la demo.
• En la demo, el administrador no está identificado correctamente.

Feedback relacionado con el desarrollo del proyecto

• Necesitan ensayar más para mejorar la velocidad de la presentación.
• El concepto de pagos anónimos no queda claro.
• El storyboard de inversores carece de datos relevantes.
• Falta incluir el número de usuarios en los cálculos de costes y beneficios.

Grupo 3 (Eventbride)

Feedback relacionado con la presentación

• El inicio ha sido efectivo y ha gustado a Cristina.
• Mejoraron el seguimiento de los problemas en comparación con versiones anteriores.
• El tamaño de la fuente en la demo y el volumen son inadecuados.
• Según Pablo, la demo no puede tener música de Angry Birds.

Feedback relacionado con el desarrollo del proyecto

• Justificar el impacto del mercado en los costes.
• Incluir más información sobre los usuarios pilotos (clientes potenciales reales).
• Detallar las funcionalidades que desean los usuarios pilotos.
• La desviación del rendimiento no es realmente un problema, sino algo normal.
• Implementar una política de cancelación clara.

Grupo 4 (Borroo)

Feedback relacionado con la presentación

• Según Pablo, la demo es poco profesional. Debe considerarse el contexto de la aplicación y el público al que va dirigida.
• La demo carece de coherencia según Pablo.
• Falta un elevator pitch claro y efectivo.
• Mucha información sobre costes.
• No se menciona el volumen de feedback recibido.

Feedback relacionado con el desarrollo del proyecto

• Según Pablo, deberían tener usuarios reales ya.
• La fianza es un aspecto importante que debería haber recibido más prioridad.

Grupo 6 (FisioFind)

Feedback relacionado con la presentación

• La imagen gráfica es buena y coherente, destacando un anuncio muy llamativo.
• Buen inicio efectivo y elevator pitch.
• Según Cristina, la demo está muy bien hecha, aunque Pablo opina lo contrario.
• Según Pablo, la parte "anuncio" de la demo sobra porque no es necesaria en este contexto (pero sí será útil en el futuro).

Feedback relacionado con el desarrollo del proyecto

• El proyecto está avanzado y presenta funcionalidades complejas, lo cual es positivo.
• Incluyen una política de cookies.
• Según Pablo, no deben usar los puntos de historia de usuario para estimar el estado futuro del proyecto.

Semana 8

Grupo 1 (Holos)

Feedback relacionado con la presentación

• Calidad de la demo:
  • Mejorar los niveles de zoom en la demo para garantizar que todos los detalles sean visibles.
  • Prestar atención al audio, ya que se percibió como deficiente y afectó la fluidez natural de la presentación.
  • El anuncio fue considerado demasiado informal. Se sugiere medir cuidadosamente el uso del humor, especialmente cuando aborda temas controvertidos, para evitar malentendidos o percepciones negativas.
• Claridad y accesibilidad:
  • Asegurarse de que los contenidos de la presentación sean comprensibles para un público más amplio, incluidas personas externas a la asignatura. Esto implica simplificar términos técnicos y proporcionar contexto adicional cuando sea necesario.

Feedback relacionado con el desarrollo del proyecto

• Inicio del testing:
  • Es necesario comenzar con las pruebas (testing) lo antes posible para validar las funcionalidades del proyecto y detectar posibles problemas.
• Medidas específicas y detalladas:
  • Las medidas presentadas deben ser más detalladas y concretas. Evitar generalidades y profundizar en aspectos específicos que permitan una mejor evaluación del progreso.
• Acciones con usuarios pilotos:
  • No quedó claro qué acciones concretas se han realizado con los usuarios pilotos. Se recomienda documentar y presentar estas acciones de manera clara, destacando cómo se ha utilizado su feedback para mejorar el proyecto.
• Áreas de mejora:
  • Se percibe margen para mejorar tanto en la estructura de la presentación como en la claridad de los contenidos. Identificar áreas específicas que puedan optimizarse para futuras iteraciones.

Grupo 2 (Gastrostock)

Feedback relacionado con la presentación

• Inicio efectivo:
  • El inicio fue ajustado en función del feedback de la semana pasada.
• Anuncio:
  • El anuncio fue destacado como llamativo y concurrente, captando bien la atención del público.
• Errores en textos:
  • Se detectaron fallos en algunos textos de la presentación. Revisar cuidadosamente el contenido para evitar errores ortográficos o de redacción.
• Correo electrónico de contacto:
  • Falta incluir el correo electrónico de contacto en la pantalla final de la presentación para facilitar la interacción posterior.
• Imágenes con derechos de autor:
  • Tener precaución al usar imágenes que puedan tener derechos de copyright. Optar por recursos libres de derechos o generar contenido propio para evitar problemas legales.

Feedback relacionado con el desarrollo del proyecto

• Costes:
  • Es necesario mostrar claramente los gastos, ingresos y puntos de equilibrio en el análisis financiero. Esto ayudará a evaluar mejor la viabilidad económica del proyecto.
• Reflexión sobre el esfuerzo del equipo:
  • No es aceptable que cinco personas no hayan contribuido esfuerzo al proyecto. Se sugiere realizar una reflexión interna y proponer soluciones para mejorar la colaboración y responsabilidad del equipo.
• Volumen de mercado:
  • Incluir información sobre el volumen de mercado que se aspira a alcanzar en los hitos importantes. Esto permitirá contextualizar mejor las metas del proyecto y su impacto potencial.
• Facilidad de uso de la aplicación:
  • Demostrar claramente que el uso de la aplicación (por ejemplo, gestionar el stock) es sencillo e intuitivo. Esto puede lograrse mediante ejemplos prácticos en la demo o explicaciones detalladas.
• Potencial cliente:
  • Profundizar en la descripción del perfil del potencial cliente para reforzar la relevancia y aplicabilidad del proyecto en el mercado objetivo.

Grupo 3 (Eventbride)

Feedback relacionado con la presentación

• Aspectos visuales del anuncio:
  • Los aspectos visuales del anuncio fueron muy bien recibidos, aunque se mencionaron algunas áreas de mejora.
• Calidad del audio en el anuncio:
  • La música en el anuncio dirigido a inversores estaba demasiado alta, lo que dificultaba escuchar las voces.
• Claridad en la demo:
  • Falta una introducción clara antes de la demo para explicar qué se va a mostrar.
  • Mejorar las explicaciones en pantalla durante la demo para que el público entienda mejor lo que está viendo.
  • Implementar un narrador o guía que facilite la comprensión de la demo y evite confusiones sobre quién es quién en la presentación.
• Datos de marketing:
  • Incluir porcentajes cuando se mencionen datos de marketing para proporcionar contexto y claridad. Esto también es relevante para los inversores.

Feedback relacionado con el desarrollo del proyecto

• Aspectos legales:
  • El tratamiento de los aspectos legales fue destacado como excelente y muy completo.
• Análisis para inversores:
  • Los inversores no están interesados en los términos técnicos de CapEx y OpEx, sino en detalles como el análisis de mercado, el nicho objetivo y cómo el proyecto planea crecer.
  • Proporcionar ejemplos claros de paquetes de inversión, como porcentajes de acciones o retornos esperados en un período determinado (por ejemplo, "Invierte X y gana Y en Z meses").
• Resolución de problemas:
  • Es necesario incluir medidas específicas que muestren cómo se están resolviendo los problemas identificados. Esto ayudará a transmitir progreso y transparencia.
• Reconocimiento positivo:
  • Se valoró positivamente que el equipo esté orgulloso de su trabajo. Ver su motivación y buen desempeño es inspirador y refleja un ambiente colaborativo.

Grupo 4 (Borroo)

Feedback relacionado con la presentación

• Anuncio:
  • El anuncio fue muy bien recibido, destacando su profesionalidad y la música, que le dio un toque muy atractivo.
• Evitar coletillas:
  • Evitar el uso de palabras como "seguidamente", ya que pueden restar fluidez a la presentación.
• Eslogan:
  • Buscar un eslogan claro y memorable que refuerce la identidad del proyecto y sea fácil de recordar.
• Demo:
  • Mejorar la claridad en la demo destacando qué funcionalidades se han implementado basadas en el feedback de los usuarios pilotos.
  • Es importante que la demo muestre claramente lo que se está presentando, evitando confusiones.

Feedback relacionado con el desarrollo del proyecto

• DAFO:
  • Se valoró positivamente cómo las debilidades fueron contrarrestadas con ventajas y cómo se equilibraron las amenazas con las oportunidades.
• Estimación de usuarios y costes:
  • Mejorar la estimación de usuarios incluyendo escenarios pesimistas, esperados y optimistas.
• Categorización del feedback:
  • Categorizar el feedback de los usuarios pilotos de manera más específica (por ejemplo, UX en lugar de "feedback visual").
  • No mezclar tipos de feedback. Diferenciar claramente entre aspectos urgentes y estéticos, ya que son dimensiones distintas.
• Clasificación del feedback:
  • Mejorar la clasificación del feedback para evitar confusiones. Separar claramente los tipos de feedback (urgente, estético, funcional, etc.) para facilitar su análisis y priorización.

Grupo 6 (FisioFind)

Feedback relacionado con la presentación

• Inicio efectivo:
  • El inicio fue muy efectivo, claro y captó perfectamente la atención del público. Además, logró empatizar bien con los asistentes, lo cual es un punto fuerte a mantener.
• Presentación del equipo:
  • La forma de presentar al equipo fue destacada como perfecta, mostrando cohesión y claridad en los roles asignados.
• Demo:
  • La demo fue percibida como muy profesional, pero se sugiere mejorar la transición entre secciones para evitar saltos bruscos. Se recomienda usar iconos o elementos visuales que guíen mejor al espectador.
  • Reducir la velocidad de interacción en la demo y no intentar enseñar todo a la vez. Explicar cada parte de manera más pausada y clara para facilitar la comprensión.
• Mejoras destacadas:
  • Las mejoras implementadas fueron destacadas de forma efectiva en la demo, lo cual refuerza la percepción de progreso y profesionalidad.

Feedback relacionado con el desarrollo del proyecto

• Feedback de usuarios pilotos:
  • Aún están pendientes de recopilar y analizar el feedback de los usuarios pilotos.
• Customer agreement:
  • En el customer agreement falta incluir aspectos clave relacionados con el SLA (Service Level Agreement).
• Realismo en imágenes de usuarios:
  • Añadir imágenes de usuarios más realistas y asegurarse de que la información contenida no sea repetitiva. Evitar patrones evidentes, como imágenes de usuario duplicadas, para aumentar la credibilidad del proyecto.
• Tareas de implementación en el PPL:
  • Tienen muchas tareas de implementación pendientes para el PPL. Es importante que sean conscientes de la carga de trabajo y planifiquen adecuadamente para cumplir con los plazos.
• Priorización del feedback:
  • Mejorar la priorización del feedback recibido de los usuarios pilotos. Clasificarlo de manera clara y enfocarse en resolver primero los aspectos más críticos.

Semana 9

Grupo 1 (Holos)

Feedback relacionado con la presentación

• Hilo de discurso y ritmo:
  • El hilo de discurso y el ritmo de la presentación fueron valorados positivamente. Se percibió como fluido y bien estructurado.
• Anuncio de inversores:
  • El anuncio dirigido a inversores fue destacado por su dinamismo, considerado adecuado y efectivo para captar la atención del público objetivo.
• Claridad en los roles:
  • No quedaron claros los roles en el anuncio. Se sugiere validar los vídeos con alguien que tenga un perfil similar al público objetivo para asegurar que los roles y mensajes sean comprensibles y efectivos.
• Calidad del audio:
  • Hubo problemas de audición durante la presentación. Realizar ejercicios de vocalización puede ayudar a mejorar la claridad y proyección de la voz.

Feedback relacionado con el desarrollo del proyecto

• Explicación de problemas:
  • Aunque la forma de comentar los problemas fue valorada positivamente, aún falta explicitar el horizonte temporal o plazo para la resolución de dichos problemas. Esto permitirá tener una visión más clara del progreso.
• Nivel de automatización:
  • Mejorar el nivel de automatización de la aplicación, especialmente en el testing. Se recomienda explorar herramientas como Playwright para optimizar este proceso.
• Pruebas end-to-end automatizadas:
  • Incorporar pruebas end-to-end automatizadas para garantizar la calidad y estabilidad del producto.
• Velocidad de revisiones de código:
  • Mejorar la velocidad de las revisiones de código. Medir y reducir el tiempo promedio de revisión será crucial para agilizar el desarrollo del proyecto.

Grupo 2 (Gastrostock)

Feedback relacionado con la presentación

• Adaptación a contratiempos:
  • El equipo ha demostrado una gran capacidad para adaptarse a los contratiempos relacionados con algunos miembros del grupo, lo cual es un punto muy positivo.
• Guion y realización del anuncio:
  • El guion y la realización del anuncio fueron muy bien valorados, destacando su calidad y efectividad.
• Uso de porcentajes:
  • Se destacó positivamente el uso del porcentaje de bares en la presentación, ya que añade credibilidad y contexto al proyecto.
• Killer opener:
  • El killer opener fue percibido como demasiado atrevido y podría interpretarse como gordofobia. Es importante ajustar este elemento para evitar malentendidos o percepciones negativas.
• Duración del anuncio:
  • El principio del anuncio es demasiado largo, y en general, su duración excede lo recomendable. Se sugiere acortarlo para mantener la atención del público.

Feedback relacionado con el desarrollo del proyecto

• Paquetes de inversión:
  • Es necesario incluir paquetes de inversión claros en el anuncio dirigido a inversores. Esto permitirá captar mejor su interés y facilitará la toma de decisiones.
• Números en el anuncio:
  • Mostrar números concretos en el anuncio (como estimaciones de mercado, beneficios, etc.) para aumentar la credibilidad y el impacto del mensaje.
• Gráfica de costes:
  • No es necesario separar los costes fijos y variables en gráficas distintas. Pueden mostrarse juntos en una misma gráfica para simplificar la visualización.
• Matriz de rendimiento:
  • Detallar más la matriz de rendimiento, evitando limitarse a un solo número. Individualizar el rendimiento de cada miembro del equipo para proporcionar una visión más completa.
• Evolución de las soluciones:
  • Mostrar claramente la evolución de las soluciones implementadas para los problemas identificados. Esto ayudará a evidenciar el progreso del proyecto.
• CapEx:
  • Recordar que los CapEx corresponden a costes capitalizables. Asegurarse de clasificarlos correctamente en el análisis financiero.

Grupo 3 (Eventbride)

Feedback relacionado con la presentación

• Acabado de la presentación:
  • El acabado de la presentación fue destacado como muy superior al de otras aplicaciones actuales. Se nota el esfuerzo dedicado y el tiempo invertido en mejorar los detalles.
• Demostración:
  • La demo debe seguir una historia coherente en lugar de ser simplemente un listado de funcionalidades. Esto permitirá que el público conecte mejor con el producto.
  • Se sugiere que la demo muestre todo el potencial de la aplicación mediante un recorrido por un escenario realista y atractivo.
• Tono del anuncio:
  • Es importante ajustar el tono del anuncio según el público objetivo. Para inversores, se recomienda reducir el nivel de informalidad y centrarse en aspectos más profesionales.
  • Los efectos deben estar alineados con el público al que va dirigido el mensaje. Evitar excesos que puedan restar seriedad o credibilidad.
• Demo como herramienta de interés:
  • La demo debe ser lo suficientemente atractiva como para que alguien externo entienda el valor de la aplicación y decida utilizarla. Debe generar interés y transmitir claramente su utilidad.

Feedback relacionado con el desarrollo del proyecto

• Información del mercado:
  • Incluir datos sobre el potencial del mercado y cómo la inversión puede generar retornos significativos. Esto ayudará a captar el interés de los inversores.
• Paquetes de inversión:
  • En lugar de presentar paquetes de inversión cerrados, se recomienda hablar directamente con los inversores para llegar a acuerdos personalizados basados en sus necesidades y expectativas.
• Estructura de problemas:
  • Mejorar la estructura de presentación de los problemas utilizando el formato: Problema → Medida → Objetivo → Trazabilidad. Esto permitirá una mejor comprensión y seguimiento del progreso.

Grupo 4 (Borroo)

Feedback relacionado con la presentación

• Trabajo general:
  • Se destacó el buen trabajo realizado por el equipo, evidenciando un esfuerzo notable en la preparación y ejecución de la presentación.
• Uso de muletillas:
  • El presentador ha reducido significativamente el uso de muletillas, lo cual mejora la fluidez y profesionalidad de la presentación.
• Presentación del equipo:
  • La forma en que se presentó al equipo fue eficiente y rápida, destacando como un punto positivo.
• Demo:
  • La demo fue valorada muy positivamente, considerada clara, atractiva y bien estructurada.
• Claridad en la demo:
  • Es necesario explicar al principio de la demo qué se va a mostrar para que el público tenga una idea clara de lo que verá.
• Datos en el anuncio de inversores:
  • Evitar frases sacadas "de la manga" en el anuncio de inversores. Siempre que se mencionen datos impresionantes, deben ir respaldados por cifras concretas o una fuente confiable.

Feedback relacionado con el desarrollo del proyecto

• Claridad entre alquiler y venta:
  • Actualmente hay confusión entre si el proyecto está orientado al alquiler o a la venta, ya que tanto el anuncio como el killer opener parecen abordar ambas soluciones. Es importante clarificar que el foco es el alquiler.
• Opciones de inversión:
  • Falta incluir las opciones de inversión (paquetes) en el anuncio dirigido a inversores.
• Evolución de los datos:
  • Sería útil incluir diferencias de datos entre semanas, utilizando flechas o indicadores visuales que muestren si han subido o bajado con respecto a la semana anterior. Esto permitirá visualizar mejor la evolución del proyecto.
• Priorización del feedback:
  • La priorización del feedback fue bien realizada, destacando varios apartados de manera clara y efectiva. Este enfoque debe mantenerse en futuras iteraciones.

Grupo 6 (FisioFind)

Feedback relacionado con la presentación

• Demo:
  • La demo fue muy bien recibida, especialmente por la clara comparación entre el "antes" y el "después", lo cual resultó impactante y efectivo.
• Anuncios específicos:
  • La idea de crear anuncios específicos para características nuevas fue valorada positivamente, ya que permite destacar mejor las funcionalidades clave del proyecto.
• Vocalización en los vídeos:
  • Se sugiere mejorar la vocalización en los vídeos para garantizar que el mensaje sea claro y comprensible.
• Redundancia del video final:
  • El video final fue percibido como redundante. Es importante evitar repeticiones innecesarias y centrarse en contenido que aporte valor adicional.

Feedback relacionado con el desarrollo del proyecto

• Datos e iconos realistas:
  • Evitar el uso de datos o imágenes genéricas en las demos. Incluir datos e imágenes realistas, como fotos de fisioterapeutas reales, para aumentar la credibilidad y el impacto visual.
• Anuncio para inversores:
  • El anuncio dirigido a inversores no cumplió con las expectativas. Se recomienda revisar el feedback de otros grupos y ajustar el contenido para que sea más atractivo y relevante para este público objetivo.
• Aspectos técnicos en la demo en directo:
  • En la demo en directo, uno de los problemas identificados fue el zoom. Es necesario abordar aspectos técnicos como este para mejorar la experiencia del usuario durante la presentación.

Semana 10

Grupo 1 (Holos)

Feedback relacionado con la presentación

• Inicio de la presentación:
  • El inicio fue percibido como poco efectivo debido al ruido en la clase y problemas con el micrófono. Es fundamental garantizar que el inicio de la presentación sea claro y profesional para captar la atención del público.
• Dinamismo y ritmo:
  • Se percibió una actitud demasiado relajada durante la presentación. Se sugiere variar los ritmos y añadir más dinamismo para mantener el interés del público.
• Contexto geográfico:
  • Falta indicar si los datos presentados en el anuncio de inversores aplican a España, Europa u otra región específica. Proporcionar este contexto es clave para que la audiencia entienda mejor el alcance del proyecto.
• Claridad en términos técnicos:
  • Unificar los términos utilizados, como "escrow/mediador". Se sugiere usar "mediador" porque es un término más comprensible para el público general.

Feedback relacionado con el desarrollo del proyecto

• Volumen económico y accesibilidad:
  • No se especificó el volumen económico de los usuarios potenciales (artistas) ni cuán asequible sería la herramienta para ellos. Este dato es crucial para evaluar la viabilidad del proyecto.
• Target audience:
  • Es importante considerar si el target audience (por ejemplo, si realmente quieren captar la atención de los inversores en Bitcoin) realmente coincidiría con los usuarios objetivo de la herramienta para artistas.

Grupo 2 (Gastrostock)

Feedback relacionado con la presentación

• Ritmo y estructura:

  • Buen ritmo de presentación, con una forma efectiva de hilar las ideas.

• Anuncio inicial:

  • Al anuncio inicial le falta un poco más de información para contextualizar mejor el proyecto.

• Uso del tiempo verbal:

  • No hablar en futuro al presentar el equipo, ya que estamos ya terminando y esto puede generar confusión sobre el estado actual del proyecto.

• Posición de la demo:

  • La demo no debe ir al final; es mejor colocarla antes de la presentación del equipo para mantener el interés del público.

• Vídeo de inversores:

  • No hay vídeo dirigido a inversores. Es importante incluir uno, pensando en el target audience y manteniendo un tono formal.

• Claridad en la demo:

  • La demo va muy rápido y no se entiende claramente de qué trata la aplicación. Se sugiere centrarse en los casos de uso clave y destacar lo que diferencia al proyecto de la competencia.

Feedback relacionado con el desarrollo del proyecto

• Exceso de detalles en costes:

  • Proporcionar demasiados detalles sobre los costes puede restar claridad y desviar el foco de los aspectos más relevantes del proyecto.

• Transición entre secciones:

  • No pasar directamente de la parte de inversores a la presentación del equipo sin una transición adecuada. Esto puede romper la línea argumental natural.

• Seguimiento de la línea argumental:

  • Es importante seguir la línea argumental dada para mantener una narrativa coherente y fluida que guíe al público de manera natural.

Grupo 3 (Eventbride)

Feedback relacionado con la presentación

• Uso de elementos visuales:

  • El uso de la tarta fue muy acertado y gustó mucho. Se sugiere ampliar esta idea para reforzar su impacto visual y narrativo.
  • El equipo visual estuvo muy bien presentado, lo que contribuyó positivamente a la percepción general.
  • Se sugiere revisar el contraste de colores en la presentación para mejorar la legibilidad y el impacto visual.
  • Algunas diapositivas contenían demasiado texto, lo que puede abrumar al público. Se recomienda simplificar y resaltar solo los puntos clave.

• Aspectos emotivos y estacionalidad:

  • La presentación fue muy emotiva y tuvo en cuenta aspectos clave como la estacionalidad de los clientes, demostrando un buen análisis del mercado para las campañas de marketing.

• Persona profiles:

  • Los persona profiles fueron espectaculares, destacando un diseño e información claros y relevantes.

• Killer opener:

  • No fue el mejor killer opener, puesto que tenían el listón muy alto y se arriesgaron por un tono mas formal. Ahora se sabe que se puede planear un killer opener sin un toque completamente serio para el WPL.

• Manejo de tiempos:

  • Se dedicó demasiado poco tiempo a explicar las características de la aplicación; se sugiere utilizar elementos como la tarta para reforzar esta parte.
  • La presentación del equipo ocupó demasiado tiempo, lo que puede restar atención a otros aspectos importantes del proyecto.

• Historia en la demo:

  • La demo no sigue una historia clara ni muestra los casos de uso específicos; es importante explicar cómo interactúa un usuario con la aplicación.

• Definición de roles:

  • Los roles presentados fueron demasiado genéricos, lo que generó redundancia y falta de diferenciación entre los miembros del equipo.

• Calidad de audio en vídeos:

  • En el vídeo de inversores, se detectó eco y falta de datos concretos para respaldar la propuesta de inversión.

• Diálogo en el vídeo:

  • En el vídeo, resulta poco natural que la madre mencione utilizar Eventbride en lugar de los miembros del equipo. Esto debería ajustarse para mayor credibilidad.

Feedback relacionado con el desarrollo del proyecto

• Enfoque en casos de uso:

  • Es fundamental centrarse más en los casos de uso clave y explicar cómo interactúan los usuarios con la aplicación para transmitir mejor su valor diferencial.

• Datos para inversión:

  • Falta incluir datos concretos y convincentes en la propuesta para inversores, lo que es crucial para captar su interés y confianza.

Grupo 4 (Borroo)

Feedback relacionado con la presentación

• Ritmo, estructura y expresión:

  • Buen ritmo y calidad general de la presentación.
  • Evitar frases redundantes o ambiguas.
  • Recomiendan cuidar las transiciones y mantener una línea argumental coherente que conecte todas las secciones de la presentación.

• Longitud de vídeos:

  • El anuncio inicial parece repetitivo y se puede reducir para ser más efectivo. Un mejor enfoque sería añadir información clave que genere interés desde el inicio.
  • La demo es demasiado corta y rápida, lo que dificulta entender claramente el funcionamiento y propósito del proyecto.

• Profundidad y datos técnicos:

  • Se debe encontrar un equilibrio entre simplificar y proporcionar detalles técnicos relevantes, considerando que es una aplicación software siendo presentada a personas que igual no son conocedoras del lenguaje técnico en profundidad.
  • Si se menciona la cantidad de miembros en grupos específicos, es importante incluir también el número total de miembros del equipo.

• Datos reales para inversores:

  • Faltan datos concretos y reales en la sección dirigida a inversores.

Feedback relacionado con el desarrollo del proyecto

• Perfiles de usuarios:

  • Aunque se muestran cuatro perfiles de usuarios, solo se explican dos. Además, ambos perfiles alquilan, lo que genera confusión sobre las diferencias entre ellos.

• Planes de inversión:

  • Los planes de inversión parecen poco realistas o mal planificados.

Grupo 6 (FisioFind)

Feedback relacionado con la presentación

• Killer opener enlazado con anuncio inicial:

  • El killer opener ha sido bien recibido, aunque se reconoce que hay otros mejores. Sin embargo, carece de personajes o elementos narrativos claros que conecten con el resto de los vídeos.

• Estructura, presentación y fluidez:

  • La presentación no fluye de manera óptima debido al orden de las diapositivas. Se sugiere revisar la secuencia para mejorar la coherencia narrativa.
  • Explicar claramente qué representa cada vídeo (demo, anuncio, etc.) para evitar confusiones.
  • Evitar términos ambiguos como "pretende" y ser contundentes ("hace") para transmitir certeza sobre el estado actual del proyecto.
  • Hay diapositivas que se tardan demasiado tiempo en desarrollar, lo que puede desviar la atención del público. Es mejor ser conciso y directo.

• Contenido audiovisual:

  • La demo es muy profesional, pero le falta información clave para que sea completamente efectiva. Esto puede generar ambigüedad sobre el propósito del proyecto.
  • El vídeo dirigido a inversores no incluye planes de inversión concretos, lo que reduce su utilidad para ese público objetivo.
  • El anuncio inicial sobre FisioFind necesita más contexto; si alguien no está familiarizado con el proyecto, podría no entenderlo completamente.

• Roles del equipo y claridad:

  • Aunque es original presentar al equipo mediante un vídeo, es necesario especificar los roles de cada miembro de manera clara y comprensible para un público no técnico.

• Profundidad técnica y características:

  • Se dedica demasiado tiempo a describir características sin profundizar en cómo estas benefician al usuario o diferencian al proyecto. Es importante centrarse en los casos de uso clave y los beneficios principales.

• Planes de pago y objetivos:

  • Los planes de pago no especifican que son mensuales, lo que puede generar confusión. Además, falta incluir los objetivos de la campaña de marketing, un aspecto crucial para contextualizar el alcance del proyecto.

Feedback relacionado con el desarrollo del proyecto

• SEO y trabajo realizado:
  • El SEO ha sido destacado como un punto fuerte, y se nota el trabajo dedicado al proyecto. Este esfuerzo debe reflejarse también en la claridad y cohesión de la presentación para maximizar su impacto.

Semana 11

Grupo 1 (Holos)

Feedback relacionado con la presentación

• Inicio y dinámica general:
  • Muy buena elección del killer opener, especialmente usar la referencia al lunes como disparador emocional.
  • Se recomienda acortar un poco el opening para ir más rápido al grano.
  • Interacción muy natural y efectiva con la mascota Missy, lo cual aporta cercanía y originalidad.
• Claridad visual y estructura:
  • La demo fue muy bien ejecutada, mostrando claramente los casos de uso principales.
  • La diapositiva 17 contiene demasiada información y resulta difícil de entender, especialmente en cuanto al modelo de ingresos. Se sugiere simplificarla o plasmarla de forma visual en lugar de usar una fórmula. Otra opción es dejarla como transparencia oculta para usarla solo si surge la pregunta.
  • En el anuncio de inversores, se propone cambiar "pago por etapas" por "cobra por etapas", ya que el mensaje va dirigido al artista, quien no realiza pagos.
• Estilo de presentación:
  • El equipo ha mejorado notablemente su forma de presentar; esta ha sido su mejor intervención hasta ahora.
  • Ha habido buen flujo entre los distintos miembros del equipo y entre las secciones de la presentación.
  • Algunos observadores dudan de si hablar en tercera persona es efectivo o si puede generar cierta incomodidad en la narrativa. Se recomienda revisarlo para ver si se puede adaptar a una narrativa más directa y personal.
• Anuncio de inversores:
  • Bien estructurado, con los datos necesarios y citando las fuentes correctamente.

Feedback relacionado con el desarrollo del proyecto

Este apartado se encuentra en blanco ya que no se han proporcionado observaciones específicas sobre el desarrollo técnico del proyecto en esta fase.

Grupo 2 (Gastrostock)

Feedback relacionado con la presentación

• Inicio y dinámica general:
  • Muy buena energía y forma de presentar por parte del speaker, lo cual captó rápidamente la atención del público.
  • La idea del killer opener basada en el "apagón" fue original, aunque podría estar generando una percepción negativa inicial sobre la aplicación. Se recomienda reconsiderar si este enfoque refleja correctamente el valor del producto.
  • Toda la presentación está muy bien hilada, con una narrativa creativa y coherente.
• Diseño y estilo:
  • El formato sencillo de la presentación gusta mucho; aporta claridad y facilita la comprensión del mensaje.
  • La diapositiva del equipo contiene demasiado detalle; se sugiere simplificarla para centrarse solo en lo esencial.
• Contenido y estructura:
  • Buen comienzo al hablar de los competidores, mostrando claramente el espacio donde se posiciona la app.
  • Las cifras de inversión no cuadran bien con las de los competidores, lo cual puede generar confusión. Se recomienda revisarlas para asegurar coherencia entre ambos apartados.
  • En la parte de marketing, se menciona mucho lo que planean hacer, pero faltan datos del presente: qué están haciendo ya y cuáles son los primeros pasos concretos.
  • El anuncio de inversores podría mejorar incluyendo un poco más de información sobre los paquetes de inversión disponibles.
• Valoración general:
  • Enhorabuena al equipo por el esfuerzo y por haber llevado adelante un trabajo sólido y bien presentado.

Feedback relacionado con el desarrollo del proyecto

Este apartado se encuentra en blanco ya que no se han proporcionado observaciones específicas sobre el desarrollo técnico del proyecto en esta fase.

Grupo 3 (Eventbride)

Feedback relacionado con la presentación

• Aspecto general y estilo:
  • La presentación ha mejorado considerablemente a nivel estético; el cambio de diseño ha sido bien recibido.
  • En general, todo ha estado muy bien presentado, con buen ritmo y claridad.
• Claridad visual y técnica:
  • Algunas pantallas de la demo no se ven con buena calidad; se recomienda revisar iluminación, resolución o tamaño para mejorar su visibilidad.
  • En la presentación se repite el uso de términos como “pequeño” y “poco”, lo cual puede generar una percepción menos sólida del producto. Se sugiere variar el lenguaje para transmitir seguridad.
• Estructura y contenido:
  • Hay solapamiento entre el vídeo de inversores y la presentación: se explica lo mismo dos veces, lo cual resulta redundante. Se recomienda diferenciar claramente ambos contenidos o integrarlos de forma más fluida.
  • El anuncio de inversores se ha quedado un poco corto; podría ampliarse para incluir más detalles relevantes que refuercen el mensaje y generen mayor impacto.
  • Se mantiene la recomendación de evitar términos técnicos como “CapEx” o “OpEx” para que el contenido sea accesible a todo tipo de público.

Feedback relacionado con el desarrollo del proyecto

Este apartado se encuentra en blanco ya que no se han proporcionado observaciones específicas sobre el desarrollo técnico del proyecto en esta fase.

Grupo 4 (Borroo)

Feedback relacionado con la presentación

• Inicio y dinámica general:
  • El inicio efectivo ha mejorado considerablemente respecto a ocasiones anteriores, aplicando correctamente el feedback recibido anteriormente.
  • La forma de presentar ha evolucionado positivamente; se percibe más natural y segura, sin muletillas ni pausas innecesarias.
• Demostración:
  • Han incorporado bien el feedback al convertir la demo en una narrativa con historia, lo cual mejora su claridad y atractivo.
  • Sin embargo, no termina de cumplir con el objetivo deseado: se pidió una historia de uso real dentro de la aplicación, no un overview general. Se recomienda enfocarla como una experiencia de usuario concreta.
  • Hay repetición entre las imágenes mostradas en la demo y las utilizadas posteriormente en los puntos clave, lo cual resulta redundante.
• Claridad visual y técnica:
  • En la diapositiva 6, la captura del chat no se ve con claridad. Se recomienda mejorar su calidad o simplificarla para facilitar su comprensión.
  • Algunas diapositivas son demasiado teóricas y podrían eliminarse o sustituirse por contenido más práctico o visual.
• Contenido y estructura:
  • Falta incluir una breve presentación del equipo, mostrando su estructura o roles principales.
  • En la diapositiva 10, dos de los competidores mencionados no parecen ser competidores reales, sino entidades con funcionalidades muy distintas. Esto puede generar confusión. Se recomienda revisar la tabla para incluir competidores más relevantes y comparables.
  • En el anuncio de inversores faltan las fuentes de los datos utilizados. Es importante incluirlas para dar credibilidad a la información.
  • El público objetivo parece demasiado reducido. Se sugiere justificarlo como “primer segmento objetivo” o “público inicial”, dejando espacio para expansiones futuras.

Feedback relacionado con el desarrollo del proyecto

Este apartado se encuentra en blanco ya que no se han proporcionado observaciones específicas sobre el desarrollo técnico del proyecto en esta fase.

Grupo 6 (FisioFind)

Feedback relacionado con la presentación

• Inicio y dinámica general:
  • La presentación en general está muy bien ejecutada, con un buen nivel de claridad, estructura y profesionalidad.
  • Se recomienda explorar alguna forma de interacción al inicio para hacer el killer opener aún más atractivo e impactante.
• Anuncio de inversores:
  • El vídeo de inversores ha sido muy bien valorado y considerado como un posible ejemplo a seguir.
  • Sin embargo, a Pablo no le han gustado los paquetes de inversión, siguiendo su línea habitual de crítica sobre este tipo de secciones.
• Diseño y claridad visual:
  • La aplicación transmite una imagen muy profesional, lo cual refuerza la credibilidad del proyecto.
  • En la diapositiva de competidores, la diferencia entre los iconos es demasiado sutil y no queda claro cuál es el valor diferencial de FisioFind. Se recomienda revisar la visualización para mejorar su comprensión.
  • La imagen utilizada de la mujer haciendo fitness no termina de transmitir correctamente el concepto de una sesión de fisioterapia. Se sugiere elegir una imagen más representativa del servicio real.
• Demostración:
  • La demo es mejorable; se recomienda centrarse en las funcionalidades clave y dejar de lado aspectos genéricos o evidentes como la accesibilidad.
  • La organización durante la explicación del chatbot se percibe confusa o poco clara. Se recomienda revisar esa parte para mejorar la narrativa.
  • No es recomendable insertar el vídeo de la demo en pequeño dentro de la presentación, ya que resta espacio y calidad visual. Es preferible mostrarlo por separado o a pantalla completa.

Feedback relacionado con el desarrollo del proyecto

Este apartado se encuentra en blanco ya que no se han proporcionado observaciones específicas sobre el desarrollo técnico del proyecto en esta fase.